Unique ID management in disconnected database replication

ABSTRACT

A system for managing identifiers in a database replication network includes a database including data items, and a global ID space including a number of identities (IDs) for identifying data items. A replica of the database includes an existing range of IDs allocated to the replica from the global ID space, and a replica ID manager for requesting a new range of IDs from the ID space when a threshold is reached. The replica ID manager adjusts the threshold based upon usage of IDs by the replica, calculates a size of the new range of IDs based upon an ID usage rate of the replica, and includes the size in the request. An ID administrator associated with the global ID space allocates a new range of IDs to the replica in response to the request, thereby providing unique global IDs to data items in replicas of the database.

FIELD OF THE INVENTION

The present invention relates generally to systems and methods formanaging disconnected replicas of databases, and more particularly tosystems and methods for dynamically allocating ranges of uniqueidentities for data items in replicas of a database.

BACKGROUND

It is often advantageous to take one or more complete or partial copiesof a database onto separate computer systems or sites and operateapplication software against each copy of the database. There exist manymethods for managing and re-synchronizing the database copies so thatthey maintain substantially the same data content. There also existsmany methods for reconciling conflicting changes made at differentsites.

For most data items within any given database record, the value of thatitem represents some aspect of the real world, and may be any valuewithin the allowed range of values. In addition, it is also common tofind data items that exist to facilitate managing the data efficientlyand are often not meaningful to users. These items are typicallyreferred to as unique identities, or simply as IDs, which are generallyallocated by the database system. In most cases, each ID provides aglobally (within the database system) unique identifier for a datarecord, and it is vital to the integrity of the data that duplicate IDsare never created.

In the case of replicas of a database, which logically form a singledatabase system, and which exchange data between them to remainsubstantially identical in content, the IDs should remain globallyunique across all replicas. If this constraint is not maintained, thenthere may be a conflict when changes from one replica are applied toanother. In the case where IDs are used to identify records, it is oftennot practical to change the ID for a record. The record may be referredto by many other records, potentially by information beyond the reach ofthe system, and the database or application programs may not havesufficient knowledge or access to modify all of the referencinginformation.

It is therefore important in these cases to have a method for generatingIDs within a set of systems that communicate only periodically, with thegoal that the IDs generated on each system will be globally uniqueacross the aggregate of all the systems. Two main methods are commonlyused to try to solve this problem.

First, in ID space partitioning, a replica is given a large range of IDsthat it “owns” at the time the replica is created. That replica is theonly system that is permitted to allocate IDs within the owned range. Bypre-allocating sections of the total available ID space to individualreplicas, there is no possibility that two different replicas willgenerate the same ID.

The drawback with this method, however, is that in order to avoid areplica running out of IDS that it may assign to data items, the rangeowned by that replica must be large. If the total system includes manyreplicas, then the ID space may be subdivided to the point where whatmay seem initially like a relatively large space (e.g., 32 bits=roughly4 billion individual IDs) may rapidly become restrictive. The result isthat the size of the IDs must be larger than is necessitated by thelikely number of records, with consequent increases in database storagesize, data access times, and other detrimental effects.

Alternatively, to reduce the size of the system-wide ID space,probability-based approaches may be used. This approach includesdefining the IDs within a sufficiently large range such that there is alow probability that a random allocation of an ID within the range willsuffer a clash with any other IDs previously allocated. Clearly, forthis to be a reasonable proposition, the ID space needs to besufficiently large. For certain configurations with unpredictabledistribution of ID allocation between replicas, however, it may stillresult in smaller ID space requirements than the partitioning approach.Overall, this approach has the same basic drawbacks as the partitioningapproach, with the extra drawback that there remains a small butnon-zero probability that a clash may, in fact, occur.

Accordingly, it is believed that systems and methods for allocatingidentities to replicas of databases to reduce the likelihood ofconflicts would be considered useful.

SUMMARY OF THE INVENTION

The present invention is directed generally to systems and methods formanaging disconnected replicas of databases, and more particularly tosystems and methods for dynamically allocating ranges of uniqueidentities to replicas of a database that may be assigned to data itemsin the respective replicas.

In accordance with a first aspect of the present invention, a system isprovided for managing identifiers in a database replication network.Generally, the system includes a database including a plurality of dataitems, and an ID space including a number of identities (IDs) foridentifying data items included in the database. The system alsoincludes one or more replicas of at least a portion of the data items inthe database.

Each replica may include an existing range of IDs allocated to thereplica from the ID space, and a replica ID manager associated with thereplica for requesting a new range of IDs from the ID space when IDs inthe existing range of IDs reaches a predetermined threshold. The replicaID manager may be capable of adjusting the predetermined threshold basedupon a usage rate of IDs by the replica. In addition, the replica IDmanager may be responsible for assigning IDs from the replica ID spaceto data items in the replica to identify the respective data items.

Preferably, the replica ID manager calculates the size of the new rangeof IDs based upon the ID usage rate of the replica. The size of thedesired new range of IDs may be included in the request for a new rangeof IDs.

The system also includes an ID administrator associated with the IDspace, the ID administrator configured for receiving requests for rangesof IDs. Preferably, the ID administrator is configured for allocating anew range of IDs to the replica in response to the request from thereplica ID manager. In one embodiment, the ID administrator is asubsystem of the database, while in another embodiment, the IDadministrator may be resident at a different site than the database, andmay communicate with the database and/or replicas via a communicationslink. Preferably, the ID administrator allocates new ranges of IDs suchthat any new ranges of IDs exclude any IDs previously allocated by theID administrator to a replica.

In accordance with another aspect of the present invention, a method isprovided for managing identifiers allocated to one or more replicas of adatabase. Generally, the database includes a data space including aplurality of data items, and a global ID space including a plurality ofidentities (IDs) for identifying data items.

A first range of IDs may be allocated from the global ID space to areplica of the database. A request may be received from the replica fora second range of IDs, whereupon a second range of IDs may be allocatedfrom the global ID space to the replica. Preferably, a size of thesecond range of IDs is selected based upon a usage rate of IDs by thereplica. For example, the size of the second range of IDs may beselected based upon at least one of an average usage rate of IDs, acurrent usage rate of IDs, and a rate of change of usage rate of IDsover time by the replica.

In one embodiment, a request may be submitted from the replica for thesecond range of IDs. The request may be received by an ID administratorassociated the global ID space, which may allocate the second range ofIDs from the global ID space in a manner that prevents conflict with IDsallocated to another replica. Preferably, the request for a second rangeof IDs is submitted when a predetermined number of available IDs in thefirst range of IDs reaches a trigger point.

In accordance with yet another aspect of the present invention, a methodis provided for managing identifiers allocated to a replica of adatabase including a data space including a plurality of data items, anda global ID space comprising a plurality of identities (IDs) foridentifying data items. The replica may include a replica ID spaceincluding a plurality of IDs allocated from the global ID space. Usageof IDs by the replica may be monitored, for example, by an ID managerassociated with the replica ID space.

A request may be submitted, e.g., by the ID manager, for a new range ofIDs from the global ID space when the IDs from the plurality of IDsremaining unused by the replica reaches a predetermined threshold.Preferably, the request includes a size of the new range of IDs beingrequested, the size being based upon a usage rate of IDs by the replica.

In one embodiment, the replica may be a first replica thatintermittently communicates with a second replica of the database, e.g.,a master copy, for synchronizing data between the first and secondreplicas. The size of the new range of IDs in any request may beselected to provide sufficient numbers of IDs for the first replica tosatisfy ID usage by the first replica between successive communicationswith the second replica. Alternatively, the replica may intermittentlycommunicate with an ID administrator managing the global ID space, andthe size of the new range of IDs may be selected to provide sufficientnumbers of IDs for the replica to satisfy ID usage by the replicabetween successive communications with the ID administrator.

Other objects and features of the present invention will become apparentfrom consideration of the following description taken in conjunctionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic of a system for allocating IDs between a databaseand replicas of the database, in accordance with the present invention.

FIG. 2 is a flowchart showing a method for allocating ranges of IDs todisconnected replicas of a database.

FIG. 3 is a flowchart showing a method for managing IDs being used by adisconnected replica of a database.

FIG. 4 shows an exemplary allocation of IDs to disconnected replicas ofa database from a global ID space.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Turning now to the drawings, FIG. 1 shows a preferred embodiment of adisconnected database replication system 10, including a master database20, an ID space 24, an ID administrator 26, and a plurality of replicas30. Although only two replicas 30 a, 30 b are shown, it will beappreciated that any number of replicas 30 (one or more) may be createdand managed in accordance with the present invention.

The master database 20, ID administrator 26, and/or replicas 30 maycommunicate with one another, e.g., may be connected either directly orintermittently via a communications link 40. In one embodiment, thecommunications link 40 may be a network, e.g., a local area network(“LAN”), an Intranet, and/or a wireless communications network (notshown). Thus, the master database 20 and replicas 30 may simply bedifferent computers and/or users at a single location. Alternatively,the network 40 may be a wide area network, e.g., including a pluralityof several different types of networks, including, but not limited to, aLAN, an Intranet, or a wireless network. An example of such a network isthe Internet. In a further alternative, the communications link 40 maybe a dial-up link or other connection, e.g., via a telecommunicationsnetwork. Thus, in the latter alternatives, the master database 20 andreplicas 30 may be located at a plurality of separate physical locationsor sites.

The master database 20 may be provided on a computing device, such as aserver or other computer, that may include one or more processors and/ormemory (not shown). It will be appreciated by those skilled in the artthat the master database 20 and/or the computing device may includeintegrated or separate hardware components and/or software modules tosupport its operation.

Generally, the master database 20 includes a data space 22, including aplurality of data items, e.g., records, states, and/or versions, thatmay be stored in the memory of the computing device. The data itemswithin any given database record may have a value that represents someaspect of the real world, and may be any value within the allowed rangeof values. In an exemplary embodiment, the data records may be relatedto geographic information systems, e.g., mapping and analysing spatialdata, such as geographic data, and/or engineering designs. The subjectmatter of the data space 22, however, is not important to the presentinvention, except that one of the goals of the present invention is tofacilitate synchronizing data and/or preventing conflicts between dataitems in disconnected replicas.

The replicas 30 may be provided on separate computing devices, such asdesktop computers or other fixed workstations, and/or mobile or portabledevices, such as laptops, personal digital assistants (“PDA's”), and thelike (not shown). Each replica 30 may include one or more processorsand/or memory (not shown), similar to the master database 20 above, forsupporting its operation. Each replica 30 generally includes a replicadata space 32 stored in memory of the computing device, which may be areplica of all or a portion of the data space 22 of the master database20.

The ID space 24 includes a range of available identities or “IDs” thatmay be allocated to the master database 20 and/or the replicas 30. TheIDs may be used as unique identifiers to identify data items added to,modified in, and/or deleted from the data spaces 22, 32 of the masterdatabase 20 and/or the replicas 30. The ID space 24 may have a fixedsize globally, although allocation of the IDs from the ID space 24 tothe master database 20 and/or the replicas 30 may change dynamically, asexplained further below. Alternatively, a plurality of ID spaces (notshown) may be provided, e.g., associated with individual tables or othersubsystems of the data space 22. Ranges of IDs available in each ofthese ID spaces may be allocated in a similar manner to that describedbelow for a single ID space 24, as will be appreciated by those skilledin the art.

The ID administrator 26 is responsible for allocating IDs from the IDspace 24 to the master database 20 and/or to each of the replicas 30.The ID administrator 26 generally has ultimate allocation authority overthe ID space 24 in order to prevent allocation errors or conflicts.Optionally, the ID administrator 26 may perform other operations notimportant to the present invention, such as generating a replica dataspace to create a replica, synchronizing replicas 30 with each otherand/or with the master database 20, and/or resolving conflicts.

In the embodiment shown, the ID space 24 and the ID administrator 26 arepart of the master database 20, i.e., may be modules or subsystems inthe server or other computing device (not shown) supporting the masterdatabase 20. Alternatively, the ID space 24 and/or ID administrator 26may be provided on one or more separate devices and/or at one or moredifferent locations than the master database 20. Consequently, the IDadministrator 26 may communicate with the master database 20 via thecommunications link 40. Thus, the ID space 24 and the ID administrator26 may be directly or indirectly associated with the master database 20.If the ID space 24 and ID administrator 26 are indirectly associatedwith the master database 20, the master database 20 may be a peer copyof an original database, similar to the replicas 30.

Each replica 30 includes a replica ID space 34, including a range of IDsallocated to the respective replica 30 from the ID space 24. Inaddition, each replica 30 includes an ID manager 36 for receiving and/orrequesting ranges of IDs from the ID space 24. The IDs available in thereplica ID space 34 may be assigned to records or other data items addedto, modified in, and/or deleted from the replica data space 32, e.g., ina monotonic manner as described further below. Similarly, the masterdatabase 20 may include its own allocated ID space and/or ID manager(not shown) that may operate similar to those included in each of thereplicas 30, particularly if the ID space 24 and the ID administrator 26are indirectly associated with the master database 20.

Turning to FIG. 2 (with continued reference to FIG. 1), a method isshown for allocating ranges of IDs, e.g., using the ID administrator 26.First, at step 110, when a replica 30 is created, an initial range ofIDs may be allocated to the replica 30 by the ID administrator 26. Therange may simply include two values, e.g., a lower limit and an upperlimit of the range, or another mechanism for defining a contiguous rangeof IDs. Alternatively, the ID administrator 26 may allocate a range ofIDs including a unique set of noncontiguous IDs, although this may bedisfavored because of the increased management involved. The defaultvalue of the range of IDs may be fixed, or may be selected based upon asize of the data space 22 upon which the replica 30 is based, ananticipated rate of usage of IDs by the replica 30, or other factors.

Preferably, the IDs in each range of IDs initially allocated to eachreplica 30, and subsequently allocated in response to each request, areunique from the IDs allocated in previous ranges of IDs by the IDadministrator 26. Thus, when a replica assigns a particular ID to one ormore data items, those data items may be uniquely identified globally,i.e., throughout the database system 10. This may substantiallyeliminate the risk of conflicts, i.e., that multiple replicas may assigndifferent data items to the same ID.

At step 112, the ID administrator 26 may advance a counter to the upperlimit of the range of IDs assigned. For example, if the counter isinitially at a value “x,” generally an integer, and the range of IDs hasa size n₁, the counter may be advanced to (x+n₁−1). Thus, the range ofIDs initially allocated includes the values from x, (x+1), . . .(x+n₁−1) in this example.

At step 114, the ID administrator 26 may receive a request from the IDmanager 36 of a replica 30 for an additional range of IDs from the IDspace 24. The request may originate from any one of the replicas 30associated with the master database 20 (or may originate from the masterdatabase 20 itself). In response to the request, the ID administrator 26may allocate a new range of IDs from the ID space to the replica 30 (orto the master database 20), and transmit the new range of IDs back tothe ID manager 36 of the respective replica 30. Alternatively, the IDadministrator 26 may periodically query each ID manager 36 to inquirewhether the respective of replica ID space 35 is running out of IDs,rather than wait for the ID manager 36 to initiate a request.

At step 118, the counter may be advanced to the upper limit of the newrange of IDs. The range of IDs allocated in response to a requestgenerally start at the point to which the counter was previously moved.Continuing the previous example, if a new range of IDs having a size n₂is allocated in response to the request, the counter may be advanced to(x+n₁+n₂−1). Thus, the range of IDs allocated includes the values(x+n₁), (x+n₁+1), . . . (x+n₁+n₂−1).

These steps may be repeated during the life of the database system,e.g., each time an additional replica 30 is created, and/or each time arequest is received from a replica 30 for a new range of IDs. Thecounter may be advanced after each request/allocation transaction,thereby ensuring that a unique set of IDs is allocated to the replicasin response to each request.

When the ID administrator 26 transmits a reply to the ID manager 36 ofthe replica 30 including its new ID range, the IDs allocated to thereplica 30 may be removed from the list of IDs available for subsequentallocation (or that the master database 20 owns if the ID space 24 isdirectly associated with the master database 20). Conversely, the IDsallocated to the ID space 24 may not be allocated to any other replica,nor to the master database 20. In most implementations, this is achievedautomatically by advancing the counter to the upper limit of each newrange of IDs allocated to a replica, as described above, althoughalternatively, the ID administrator 26 may inventory each individual ID.

Turning to FIG. 3 (with continued reference to FIG. 1), a method isshown for managing the replica ID space 34 of a replica 30 using an IDmanager 36 associated with the replica 30. Generally, the ID manager 36may be a module or subsystem of the replica 30 for monitoring usage ofan existing range of IDs allocated to the respective replica 30. At step120, the ID manager 36 may be responsible for assigning IDs from thereplica ID space 34 to data items added to, modified in, and/or deletedfrom the replica data space 32, although alternatively thisresponsibility may be assigned to another subsystem (not shown) of thereplica 30.

At step 122, the ID manager 36 may periodically submit a request to theID administrator 24 for a new range of IDs. For example, the replica 30may periodically connect with the master database 20 (and/or otherreplicas 30) to synchronize and/or exchange data. It may be efficient toinclude a request for a new range of IDs while the replica 30 is alreadyconnected to the master database 20, e.g., to “top off” the range of IDsavailable in the replica ID space 34, as explained further below.

Alternatively, or in addition, at step 124, the ID manager 36 maymonitor the replica ID space 34 to determine whether the available IDshave fallen to a predetermined threshold. For example, the ID manager 36may monitor whether the number of IDs in the replica ID space 34 stillavailable for assignment to data items is reduced to a predeterminednumber of IDs, i.e., thereby defining a trigger point. Alternatively,the ID manager 36 may monitor the used IDs for a predetermined value tobe used or a predetermined level of used IDs to be reached. If theavailable IDs still exceeds the trigger point, the ID manager 36 mayresume previous operations, e.g., assigning IDs, as indicated by 126.

Once the available IDs falls to the trigger point, the ID manager 36 mayact, e.g., to submit a request for a new range of IDs at step 128.Preferably, the trigger point takes into account a safety factor, e.g.,based upon an expected worst-case amount of time before arequest/allocation transaction may be completed. For example, assumethat the normal size of a new range of IDs that is allocated to areplica during a request/allocation transaction is two thousand (2,000)IDs, and that a factor of safety of three (3) is desired. If the replica30 connects with the master database 20 only once per day, then the IDmanager 36 would want to ensure that the replica ID space 34 hassufficient available IDs to satisfy three days worth of usage.Therefore, the trigger point would be 6,000 available IDs in the replicaID space 34.

When the new range of IDs is received by the ID manager 36 of a replica30, the new IDs are added to the replica ID space 34. Thus, a replica 30may “own” a plurality of ID ranges in the replica ID space 34, e.g., aninitial range and one or more new ranges added in response to requestsfor additional IDs.

The replica ID space 34 may also be divided another way, i.e., betweenthe “working” ID range including IDs currently being assigned to dataitems, and zero or more “stock” ID ranges for when the working range isdepleted. The stock ID ranges may become the working range in turn whenthe IDs in the current working range are exhausted. Most of the time, areplica may own no more than one new range for any ID space, althoughthe systems and methods of the present invention may allow for multipleranges of IDs being allocated to a replica, which may increase theflexibility of the system. Thus, the ID manager 36 may monitor usage ofIDs by the replica 30 to ensure that, when the last ID in a first range(the working range) is used, the next ID assigned to a data item is fromthe next available range owned by the replica 30.

Optionally, the ID manager 36 may issue a warning to a user of thereplica 30 once the trigger point is reached (not shown in FIG. 3),e.g., to allow the user to initiate connection with the master database20 and/or ID administrator 26. This operation may be particularly usefulfor a replica 30 that is substantially isolated from the master database20 and/or system administrator 26, e.g., is only connected when the useraffirmatively decides to initiate a connection. Thus, the ID manager 36may provide sufficient warning to allow the user to connect with themaster database 20 and/or the ID administrator in order to receiveanother range of IDs without disrupting use of the replica 30.

Another purpose of the ID manager 36 of a replica 30 may be to determinethe size of a new range of IDs to be allocated to the replica 30.Generally, the size may be determined based upon usage of IDs by thereplica 30. For example, the ID manager 36 may monitor the rate at whichthe replica 30 uses IDs and include a particular size range of IDs inits request to the ID administrator 26 that is based upon this usagerate. The usage rate may be an average usage rate, e.g., total IDs usedby a replica divided by a total number of requests made by the replica.Alternatively, a current usage rate may be used, e.g., the number of IDsused by the replica 30 since its last connection to the master database20. In a further alternative, a rate of change of ID usage over time maybe used to calculate the size of the range of IDs to request, e.g., toadjust for trends of increasing or decreasing usage by the replica 30.

Alternatively, the process of determining the size of the new range ofIDs may be performed by the ID administrator 26 rather than the IDmanager 36. However, the ID manager 36 of the replica 30 may be betterable to monitor trends in ID usage by the replica 30 between connectionswith the ID administrator 26, and therefore may provide a finergranularity.

Although the ID administrator 26 may set default values for the size ofID ranges allocated to the replicas 30, monitoring use of the IDs, e.g.,by the ID manager 36 of each replica 30, may provide a basis forself-tuning range sizes, if appropriate. Thus, the replica ID space 34for different replicas 30 may have a different ideal range size, andthat the ideal range size may well vary between replicas of the samedatabase and/or over time.

Preferably, the size of the range of IDs allocated to the replica 30 issuch that the replica 30 needs to communicate only intermittently withthe master database 20, e.g., during fixed periodic intervals. Dependingupon the application, the size of the database system, and/or otherfactors, the frequency at which the replica 30 communicates or connectswith the master database 20 may be a matter of seconds, minutes, hours,or even days, as will be appreciated by those skilled in the art.

Thus, a system administrator or other operator overseeing the databasesystem 10 may configure the ID manager(s) 34 and/or ID administrator 24for target thresholds, range sizes, and/or other parameters. Forexample, if a target connection time is once per day and a safety factorof three (3) is selected, the ID manager may try to maintain three daysaverage usage of IDs available in the replica ID space. Thus, duringnormal operation, the size of the available IDs in the replica ID spacemay range from three to four (3-4) days of ID usage.

Turning to FIG. 4, an exemplary arrangement of IDs allocated between tworeplicas of a disconnected database is shown. The database includes oneor more global ID spaces 150 (one shown), including the entire range ofIDs available for assignment to data items of the database. As explainedabove, if the database includes multiple tables or separate data spaces,a separate global ID space may be associated with each data space. Inthe example shown, the global ID space 150 includes a range starting atone (1) and continuing to greater than four thousand (4,000), i.e., tosome finite integer “N.”

Initially, the counter is set to one (1), although alternatively anyother integer may be used. When Replica 1 is created, its replica IDspace 152 is allocated a range of IDs (e.g., a default range), e.g., onethousand (1,000) IDs, ranging from 1-1,000. The counter of the global IDspace may then be advanced from one (1) to one thousand and one (1,001).When Replica 2 is created, its replica ID space 154 is also allocated arange of IDs, e.g., one thousand (1,000) IDs, ranging from 1,001-2,000.Thus, the new range of IDs begins at the current counter point,whereupon the counter may be advanced to the upper limit of the newrange of IDs, e.g., to 2,001.

Subsequently, e.g., in response to a request from Replica 1, its replicaID space 152 may be allocated another range of IDs, e.g., five hundred(500) IDs, ranging from 2,001-2,500, whereupon the counter may again beadvanced to the upper limit, 2,501. Finally, in response to a requestfrom Replica 2, its replica ID space 154 may be allocated fifteenhundred (1,500) IDs, ranging from 2,501-4,000. The counter may beadvanced to 4,001, indicating that the IDs ranging from 4,001-N continueto be available in the global ID space 152 for allocation to Replicas 1,2, or any other new replicas created. Although in the example shown, theID administrator (not shown) managing the global ID space 150 may keeptrack of which ranges have been allocated to which replicas, this extralevel of management may be unnecessary, since the counter ensures thatno overlapping or duplicate range of IDs is allocated to multiplereplicas.

Thus, the systems and methods in accordance with the present inventionprovide a dynamic method for managing the ID space of databasereplication system. For example, they may facilitate supporting morereplicas for a given size of ID space than other methods, yetsubstantially eliminate the possibility of ID allocation conflicts.

The size of the range of IDs allocated to a replica may be determinedbased upon the following criteria. First, after considering all otherfactors, smaller ranges are better.

Second, the ranges may be large enough to cover substantially all of theallocation needs within a replica until it is next able to communicatewith the master database. This may depend on the usage and connectionprofiles of the particular implementation and application. In mostcases, a “safety factor” may be built into a calculation tosubstantially reduce the chances of a replica reaching the end of itsallotted range(s) of IDs before it has a chance to be allocated anotherrange.

Finally, the range may be large enough such that the overhead of themanagement process does not create a significant communications orprocessing burden in relation to other normal processes. In mostcircumstances, the target may be to require allocation of an ID range toa replica infrequently and/or a fixed periods, e.g., no more than a fewtimes a day.

While the invention is susceptible to various modifications, andalternative forms, specific examples thereof have been shown in thedrawings and are herein described in detail. It should be understood,however, that the invention is not to be limited to the particular formsor methods disclosed, but to the contrary, the invention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the appended claims.

1. A system for managing identifiers in a database replication network,comprising: a database comprising a plurality of data items; an ID spaceincluding a number of identities (IDs) for identifying data itemsincluded in the database; a replica of at least a portion of the dataitems in the database, the replica comprising an existing range of IDsallocated to the replica from the ID space; a replica ID managerassociated with the replica for requesting a new range of IDs from theID space when IDs in the existing range of IDs reaches a predeterminedthreshold; and an ID administrator associated with the ID space, the IDadministrator configured for receiving requests for ranges of IDs, theID administrator configured for allocating a new range of IDs to thereplica in response to the request from the replica ID manager, a sizeof the new range of IDs being selected based upon an ID usage rate ofthe replica.
 2. The system of claim 1, wherein the ID administrator is asubsystem of the database.
 3. The system of claim 2, wherein thedatabase further comprises an interface for receiving the request fromthe replica ID manager and for transferring the new range of IDs to thereplica ID manager.
 4. The system of claim 1, wherein the IDadministrator is resident at a different site than the database, andwherein the database and the ID administrator comprise interfaces forcommunicating with each other via a communications link.
 5. The systemof claim 1, wherein the replica ID manager is configured for assigningIDs from the replica ID space to data items in the replica to identifythe respective data items.
 6. The system of claim 1, wherein the IDadministrator is configured for allocating the new range of IDs suchthat the new range of IDs excludes any IDs previously allocated to areplica.
 7. The system of claim 1, wherein the ID administrator isconfigured for calculating the size of the new range of IDs based uponthe ID usage rate of the replica.
 8. The system of claim 1, wherein thereplica ID manager is configured for calculating the size of the newrange of IDs based upon the ID usage rate of the replica, and whereinthe replica ID manager includes the size in the request for a new rangeof IDs.
 9. The system of claim 1, wherein the replica ID manager isconfigured for adjusting the predetermined threshold based upon a usagerate of IDs by the replica.
 10. A system for managing identifiers in adatabase replication network of a database, comprising: a databasecomprising a plurality of data items; an ID space including a number ofidentities (IDs) for identifying data items included in the database; areplica of at least a portion of the data items in the database, thereplica comprising an existing range of IDs allocated to the replicafrom the ID space; an ID manager associated with the replica formonitoring usage of IDs by the replica, the ID manager configured forsubmitting a request for a new range of IDs, the request comprising asize of the new range of IDs based upon usage of IDs by the replica; andan ID administrator associated with the ID space, the ID administratorconfigured for receiving the request from the ID manager and forallocating a new range of IDs to the replica in response to the request,the new range of IDs comprising the size requested by the ID manager.11-19. (canceled)
 20. A method for managing identifiers allocated to aplurality of replicas of a database comprising a data space including aplurality of data items, and a global ID space comprising a plurality ofidentities (IDs) for identifying data items, the method comprising:providing a replica of the database, the replica comprising a replica IDspace comprising a plurality of IDs allocated from the global ID space;monitoring usage of IDs by the replica; and submitting a request for anew range of IDs from the global ID space when the IDs from theplurality of IDs remaining unused by the replica reaches a predeterminedthreshold, the request comprising a size of the new range of IDs beingrequested, the size being based upon a usage rate of IDs by the replica.21. The method of claim 20, wherein the size of the new range of IDs isselected based upon at least one of an average usage rate of IDs, acurrent usage rate of IDs, and a rate of change of usage rate of IDsover time by the replica.
 22. The method of claim 20, wherein thereplica comprises a first replica, and wherein the first replicaintermittently communicates with a second replica of the database forsynchronizing data between the first and second replicas.
 23. The methodof claim 22, wherein the size of the new range of IDs is selected toprovide sufficient numbers of IDs for the first replica to satisfy IDusage by the first replica between successive communications with thesecond replica.
 24. The method of claim 23, wherein the second replicacomprises a master copy of the database.
 25. The method of claim 20,wherein the replica intermittently communicates with an ID administratormanaging the global ID space, and wherein the size of the new range ofIDs is selected to provide sufficient numbers of IDs for the replica tosatisfy ID usage by the replica between successive communications withthe ID administrator.